2. EL 6 ELS
  3. man-pages-fr
  4. pppd(8)

Scroll to navigation

PPPD(8) System Manager's Manual PPPD(8)

NOM

pppd - Démon du Protocole Point-à-Point (PPP)

SYNOPSIS

pppd [ nom_tty ] [ vitesse ] [ options ]

DESCRIPTION

Le Protocole Point-à-Point (PPP) fournit une méthode de transmission de datagrammes au-dessus d'une connexion série point à point. PPP est composé de trois parties : une méthode pour encapsuler des datagrammes dans une liaison série, un protocole de contrôle de lien (LCP) extensible, et une famille de protocoles de contrôle réseau (NCP) pour établir et configurer différents protocoles de niveau réseau.

Le schéma d'encapsulation est fourni par le code du pilote dans le noyau. pppd fournit le LCP de base, le support de l'authentification, et un NCP pour établir et configurer le protocole IP (appelé IPCP pour IP Control Protocol).

OPTIONS FRÉQUEMMENT UTILISÉES

<nom_tty>
Communique sur le périphérique donné. Le préfixe "/dev/" est ajouté si nécessaire. Si aucun nom de périphérique n'est donné, ou si c'est le nom du terminal connecté à l'entrée standard, pppd utilisera ce terminal, et ne "forkera" pas pour passer en arrière-plan. Une indication pour cette option provenant d'une source privilégiée ne peut pas être remplacée par un utilisateur non privilégié.
<vitesse>
Fixe le nombre de bauds à <vitesse> (un entier décimal). Sur des systèmes comme 4.4BSD et NetBSD, n'importe quelle vitesse peut être spécifiée. D'autres systèmes (Linux, SunOS...) autorisent seulement un ensemble limité de vitesses.
Fixe la table de caractères asynchrone à <table>. Cette table décrit quels caractères de contrôle ne peuvent être reçus avec succès par la ligne série. pppd demandera à son correspondant de lui envoyer ces caractères comme séquence d'échappement de 2 octets. L'argument est un nombre hexadécimal de 32 bits, chaque bit représentant un caractère : à 1 s'il faut le transmettre via esc. Le bit 0 (00000001) représente le caractère 0x00, le bit 31 (80000000) représente le caractère 0x1f ou ^_. Si plusieurs options asyncmap sont données, les valeurs sont combinées par OR. Si aucune option asyncmap n'est donnée, aucune table de caractères asynchrone ne sera négociée en réception. Le correspondant devrait alors passer tous les caractères de contrôle via une séquence d'échappement. Pour les caractères émis, utilisez l'option escape.
Demande au correspondant de s'authentifier avant d'autoriser la transmission de paquets réseau. Cette option est fixée par défaut si le système utilise une route par défaut (defaultroute). Si ni auth ni noauth n'est spécifiée, pppd n'autorisera son correspondant qu'à utiliser des adresses IP vers lesquelles le système n'a pas encore de route.
Lit les options dans le fichier /etc/ppp/peers/nom. Ce fichier peut contenir des options privilégiées, comme noauth, même si pppd n'est pas lancé par root. La chaîne nom ne doit pas commencer par / ni inclure de .. comme composant de chemin. Le format du fichier d'option est décrit plus bas.
Utilise l'exécutable ou la commande shell spécifiée par script pour initialiser la ligne série. Ce script utilise en principe le programme chat(8) pour gérer le modem et lancer la session ppp distante. Pour cette option, une valeur provenant d'une source privilégiée ne peut pas être remplacée par un utilisateur non privilégié.
Utilise le contrôle de flux matériel (RTS/CTS) pour contrôler le flux de données sur le port série. Si ni crtscts, ni nocrtscts, ni cdtrcts, ni nocdtrcts n'est passée, le contrôle de flux du port série est laissé inchangé. Certains ports série (comme celui du Macintosh) manquent d'une vraie sortie RTS. Ces ports série utilisent ce mode pour implémenter un contrôle de flux unidirectionnel. Le port série arrêtera ses envois à la demande du modem (via CTS) mais sera incapable de demander au modem d'arrêter d'envoyer à l'ordinateur. Ce mode garde la possibilité d'utiliser DTR comme ligne de contrôle du modem.
Ajoute à la table de routage du système une route par défaut utilisant le correspondant comme passerelle, une fois que la négociation IPCP est terminée. Cette entrée est supprimée quand la connexion PPP est coupée. Cette option est privilégiée si l'option nodefaultroute a été spécifiée.
Exécute le script ou la commande spécifiée par script dès la fin de la connexion pppd. Ce script peut, par exemple, envoyer au modem l'ordre de raccrocher, si les signaux de contrôle matériel du modem ne sont pas disponibles. Le script de déconnexion n'est pas lancé si le modem a déjà raccroché. Pour cette option, une valeur provenant d'une source privilégiée ne peut pas être remplacée par un utilisateur non privilégié.
Spécifie que certains caractères doivent être "protégés" : précédés d'une séquence d'échappement durant la transmission (sans prendre en compte dans ce cas l'échappement de ces caractères par la table de caractères de contrôle asynchrone, le cas échéant). Les caractères à "protéger" sont spécifiés sous la forme d'une liste de nombre hexa, séparés par des virgules. Notez que presque tous les caractères peuvent être protégés par l'option escape, contrairement à l'option asyncmap qui permet seulement de spécifier des caractères de contrôle. Les caractères qui ne peuvent pas être protégés sont 0x20 à 0x3f et 0x5e (^).
Lit les options dans le fichier nom (voir format ci-dessous). Le fichier doit être lisible par l'utilisateur qui a invoqué pppd.
Exécute le script ou la commande spécifiée par script afin d'initialiser la ligne série. Ce script utilise typiquement le programme chat(8) pour configurer le modem pour autoriser la réponse automatique. Pour cette option, une valeur provenant d'une source privilégiée ne peut pas être remplacée par un utilisateur non privilégié.
Spécifie que pppd doit créer un fichier de verrouillage (lock) style UUCP pour le périphérique série, afin d'assurer un accès exclusif au périphérique.
Règle la MRU [Unité Maximale de Réception, ou Maximum Receive Unit] à n. Pppd demandera à son correspondant de ne pas envoyer de paquets de plus de n octets. La valeur minimale est de 128, celle par défaut de 1500. Une valeur de 296 est recommandée pour les liens lents (40 octets pour l'en-tête TCP/IP + 256 octets de données). (Pour IPv6, la MRU minimale est de 1280)
Règle la MTU [Unité Maximale d'émission, ou Maximum Transmit Unit] à n. À moins que le correspondant ne demande une valeur plus petite via la négociation MRU, pppd demandera au code réseau du noyau de limiter la taille des paquets émis sur l'interface PPP àn octets. (Pour IPv6, la MTU minimale est 1280).
Active l'option "passive" du LCP. Avec cette option, pppd essaiera d'établir une connexion ; si aucune réponse n'est reçue du correspondant, pppd se contentera d'attendre passivement de celui-ci un paquet LCP valide, au lieu de s'arrêter, comme il le ferait sans cette option.

OPTIONS

<adresse_IP_locale>:<adresse_IP_distante>
Règle les adresses IP des interfaces locale et distante. L'une ou l'autre peut être omise. Les adresses IP peuvent être données par un nom d'hôte ou en notation décimale. L'adresse locale par défaut est la première adresse IP du système (à moins d'avoir spécifié l'option noipdefault). L'adresse distante sera obtenue du correspondant si elle n'est spécifiée par aucune option ; ainsi, dans les cas simples, cette option n'est pas nécessaire. Si une adresse IP locale ou distante est spécifiée avec cette option, pppd n'acceptera pas du correspondant une valeur différente, à moins que l'option ipcp-accept-local ou ipcp-accept-remote (respectivement) ne soit passée.
Précise l'identificateur 64 bits d'interface locale ou distante. L'un ou l'autre peut être omis. L'identificateur doit être spécifié dans la notation standard des adresses IPv6 (par ex. ::dead:beef). Si l'option ipv6cp-use-ipaddr est passée, l'identificateur local est l'adresse IPv4 locale (voir ci-dessus). Sur les systèmes qui supportent un identificateur persistant unique, comme l'EUI-48 dérivé de l'adresse MAC Ethernet, l'option ipv6cp-use-persistent peut être utilisée en remplacement de ipv6 <local>,<distant>. Autrement, l'identificateur est tiré au hasard.
Spécifie un filtre à appliquer aux paquets de données, pour déterminer quels paquets doivent être considérés comme de l'activité sur le lien, et donc remettre à zéro le compteur de repos, ou déclencher l'activation du lien, en mode connexion à la demande (demand-dialing). Cette option est utile en conjonction avec l'option idle, s'il y a régulièrement des paquets envoyés ou reçus sur le lien (par exemple des informations de routage), qui sinon empêcheraient le lien d'apparaître au repos (idle). La syntaxe d'expression-filtre est la même que celle décrite dans tcpdump(1), sauf que certains "qualificateurs" qui ne sont pas pertinents pour une ligne PPP, comme ether et arp, ne sont pas autorisés. Généralement, l'expression-filtre doit être entre apostrophes pour empêcher les espaces dans l'expression d'être interprétés par le shell. Cette option est pour le moment disponible uniquement sous NetBSD, et seulement si le noyau et pppd ont été compilés tous deux avec l'option PPP_FILTER.
Permet aux correspondants d'utiliser l'adresse ou le sous-réseau IP donné sans s'authentifier. Le paramètre est analysé comme chaque élément de la liste des adresses IP autorisées, dans les fichiers "secrets" (voir la section AUTHENTIFICATION ci-dessous).
Demande au correspondant de compresser les paquets qu'il envoie, en utilisant le schéma BSD-Compress, avec une longueur de code maximale de nr bits, et dit à pppd de compresser les paquets envoyés au correspondant, avec une longueur de code maximale de nt bits. Si nt n'est pas précisé, il est pris égal à nr. Des valeurs de 9 à 15 peuvent être utilisées pour ces paramètres. Des valeurs supérieures donnent une meilleure compression, mais consomment plus de mémoire noyau pour les dictionnaires de compression. Une valeur de 0 pour nr ou nt désactive toute compression dans la direction correspondante. Utilisez nobsdcomp ou bsdcomp 0 pour désactiver totalement la compression BSD-Compress.
Utilise un contrôle de flux matériel non standard (DTR/CTS) pour contrôler le flux de données sur le port série. Si aucune des options crtscts, nocrtscts, cdtrcts et nocdtrcts n'est passée, le contrôle de flux du port série est inchangé. Certains ports série (comme sur le Macintosh) manquent d'une vraie sortie RTS. Ces ports utilisent ce mode pour implémenter un vrai contrôle de flux bidirectionnel. L'inconvénient est que ce mode de contrôle ne permet plus d'utiliser DTR comme ligne de contrôle du modem.
Si cette option est passée, pppd relancera le "défi" d'authentification pour le correspondant toutes les n secondes.
Fixe à n le nombre maximal de transmissions de "défis" d'authentification CHAP (10 par défaut).
Fixe à n secondes le délai de redémarrage de CHAP (expiration de retransmission pour les défis). 3 secondes par défaut.
Attend jusqu'à n millisecondes après la fin du script de connexion un paquet PPP valide du correspondant. Passé ce délai, ou à la réception d'un paquet PPP valide, pppd commencera sa négociation en envoyant son premier paquet LCP. La valeur par défaut est 1000 (1 seconde). Cette période d'attente ne s'applique qu'avec les options connect et pty.
Active les sorties de débogage de la connexion. Si cette option est passée, pppd enregistrera sous une forme lisible les contenus de tous les paquets de contrôle émis ou reçus. Les paquets sont enregistrés par syslog, sous le service (facility) daemon et la priorité debug. Ces informations peuvent être envoyées directement vers un fichier en configurant correctement /etc/syslog.conf (voir syslog.conf(5)).
Désactive la négociation asyncmap, en forçant la protection de tous les caractères de contrôle par une séquence d'échappement, dans les deux directions.
Désactive la négociation MRU [Maximum Receive Unit]. Avec cette option, pppd utilisera la valeur par défaut de 1500, dans les deux directions.
Demande au correspondant de compresser les paquets qu'il envoie, en utilisant le schéma Deflate, avec une taille de fenêtre maximale de 2^nr octets, et dit à pppd de compresser les paquets envoyés au correspondant, avec une taille maximale de 2^nt octets. Si nt n'est pas précisé, il est pris égal à nr. Des valeurs de 8 à 15 peuvent être utilisées pour ces paramètres. Des valeurs supérieures donnent une meilleure compression, mais consomment plus de mémoire noyau pour les dictionnaires de compression. Une valeur de 0 pour nr ou nt désactive toute compression dans la direction correspondante. Utilisez nodeflate ou deflate 0 pour désactiver totalement la compression Deflate. Note : si le correspondant gère aussi bien les compressions BSD-Compress que Deflate, pppd demande de préférence Deflate.
Établit le lien seulement à la demande, c'est-à-dire si du trafic est présent. Avec cette option, l'adresse IP distante doit être spécifiée par l'utilisateur sur la ligne de commande ou dans un fichier d'options. Pppd commencera par configurer l'interface et la rendre accessible au trafic IP, sans se connecter au correspondant, dans l'attente de trafic. À ce moment, pppd se connectera au correspondant, entreprendra la négociation et l'authentification, etc. Ensuite, il fera passer les paquets IP sur le lien.

L'option demand implique l'option persist. Si ce comportement est indésirable, utilisez l'option nopersist après demand. Les options idle et holdoff sont également utiles en conjonction avec demand.

Ajoute le nom de domaine d à l'hôte local, à des fins d'authentification. Par exemple, si gethostname() retourne le nom porsche, mais que le nom de domaine pleinement qualifié est porsche.quotron.com, vous pouvez spécifier domain quotron.com. Pppd utilisera alors le nom porsche.quotron.com pour chercher les secrets dans le fichier secrets, et comme nom par défaut à envoyer au correspondant pour s'authentifier auprès du correspondant. Cette option est considérée comme privilégiée.
Lors de l'enregistrement (log) des paquets PAP, cette option dit à pppd d'exclure la chaîne mot de passe de l'enregistrement. Comportement par défaut.
Spécifie combien de secondes pppd doit attendre avant de relancer le lien, après sa fin. Cette option n'a d'effet que si l'option persist ou demand est utilisée. La période de "raccrochage" (holdoff) n'est pas appliquée si le lien s'est terminé parce qu'il était au repos (idle).
Spécifie à pppd de déconnecter si le lien est au repos pendant n secondes. Le lien est au repos quand aucun paquet de données n'est reçu, ni envoyé. Il n'est pas conseillé d'utiliser cette option avec l'option persist sans l'option demand. Si l'option active-filter est passée, les paquets de données qui sont rejetés par le filtre sont considérés comme un lien au repos.
Avec cette option, pppd acceptera le choix de votre correspondant pour votre adresse IP, même si l'adresse IP locale est spécifiée dans une option.
Avec cette option, pppd acceptera l'opinion de votre correspondant sur sa propre adresse IP, même si l'adresse IP distante est spécifiée dans une option.
Règle à n (10 par défaut) le nombre maximal d'émissions IPCP configure-request.
Règle à n (10 par défaut) le nombre maximal de configure-NAKs IPCP (non-acquittement) retournés avant d'envoyer des configure-Rejects à la place.
Règle à n (3 par défaut) le nombre maximal d'émissions IPCP terminate-request.
Règle à n secondes (3 s par défaut) le délai de relance IPCP (IPCP restart = expiration de réémission).
Fournit un paramètre supplémentaire aux scripts ip-up et ip-down. Avec cette option, la chaîne fournie est passée en 6e paramètre à ces scripts. [NdT : utile pour passer l'uid de l'appelant par exemple]
Règle à n (10 par défaut) le nombre maximal d'émissions IPv6CP configure-request.
Règle à n (10 par défaut) le nombre maximal de configure-NAKs IPv6CP (non-acquittement) retournés avant d'envoyer des configure-Rejects à la place.
Règle à n (3 par défaut) le nombre maximal d'émissions IPv6CP terminate-request.
Règle à n secondes (3 s par défaut) le délai de relance IPv6CP (IPv6CP restart = expiration de réémission).
Active les protocoles IPXCP et IPX. Cette option n'est pour l'instant supportée que sous Linux, et si votre noyau inclut le support IPX.
Fixe à n, un nombre hexadécimal (sans 0x), le numéro de réseau IPX dans la trame IPXCP configure-request. Il n'y a pas de valeur par défaut définie. Si cette option n'est pas spécifiée, le numéro de réseau est obtenu du correspondant. S'il ne fournit pas de numéro de réseau, le protocole IPX ne sera pas démarré.
Fixe les numéros de nœud IPX, les deux numéros séparés par un double point. Le premier, n, est le numéro de noeud local ; le second, m, est le numéro de noeud du correspondant. Chaque numéro de noeud est un nombre hexadécimal, d'au plus 10 chiffres (5 octets). Les numéros de noeud sur le réseau ipx doivent être uniques. Il n'y a pas de valeur par défaut définie. Si cette option n'est pas spécifiée, les numéros de noeud sont obtenus du correspondant.
Fixe le nom du routeur. C'est une chaîne envoyée au correspondant en tant que données d'information.
Fixe le protocole de routage. Plusieurs instances d'ipx-routing peuvent être spécifiées. L'option 'none' (0) peut être spécifiée comme seule instance d'ipx-routing. Les valeurs peuvent être 0 pour NONE, 2 pour RIP/SAP, et 4 pour NLSP.
Accepte un NAK (non-acquittement) du correspondant sur le numéro de noeud spécifié par l'option ipx-node. Si un numéro de nœud est spécifié, et non nul, le comportement par défaut est d'insister pour que ce soit la valeur utilisée. Si vous passez cette option, vous permettez au correspondant de passer outre la valeur entrée du numéro de noeud.
Accepte un NAK (non-acquittement) du correspondant sur le numéro de réseau spécifié par l'option ipx-network. Si un numéro de réseau est spécifié, et non nul, le comportement par défaut est d'insister pour que ce soit la valeur utilisée. Si vous passez cette option, vous permettez au correspondant de passer outre la valeur entrée du numéro de réseau.
Utilise le numéro de réseau du correspondant, tel qu'indiqué dans la trame configure-request. Si un numéro de réseau est spécifié pour le correspondant, et que cette option n'est pas passée, le correspondant est forcé d'utiliser le numéro de réseau que vous avez spécifié.
Fixe à n (10 par défaut) le nombre maximal de trames IPXCP configure-request que le système enverra.
Fixe à n (3 par défaut) le nombre maximal de trames IPXCP NAK que le système enverra avant de rejeter les options.
Fixe à n (3 par défaut) le nombre maximal de trames IPXCP terminate-request avant que le système local considère que le correspondant ne l'écoute pas.
Active le code de débogage du pilote PPP au niveau noyau. L'argument n est un nombre qui est la somme des valeurs suivantes : 1 pour les messages généraux de débogage, 2 pour demander que le contenu des paquets reçus soit imprimé, et 4 pour le contenu des paquets envoyés. Sur la plupart des systèmes, les messages envoyés par le noyau sont journalisés par syslog(1) dans un fichier, selon le fichier de configuration /etc/syslog.conf.
Permet à pppd de modifier les paramètres du noyau selon ce qui est nécessaire. Sous Linux, pppd activera l'IP forwarding (en mettant à 1 /proc/sys/net/ipv4/ip_forward) si l'option proxyarp est utilisée, et l'option d'adresse IP dynamique (en mettant à 1 /proc/sys/net/ipv4/ip_dynaddr) en mode connexion à la demande si l'adresse locale change.
Si cette option est passée, pppd supposera que le correspondant est mort si n echo-requests LCP sont envoyés sans qu'un echo-reply LCP valide ne soit reçu. Si c'est le cas, pppd coupera la connexion. Cette option nécessite une valeur non nulle pour lcp-echo-interval. Cette option peut permettre à pppd de se terminer après la fin de la connexion physique (ex : raccrochage modem), dans des cas où aucune ligne de contrôle matériel du modem n'est disponible.
Si cette option est passée, pppd enverra une trame LCP echo-request au correspondant toutes les n secondes. Normalement, le correspondant doit répondre par une LCP echo-reply. Cette option peut être utilisée en conjonction avec l'option lcp-echo-failure pour détecter que le correspondant n'est plus connecté.
Fixe à n (10 par défaut) le nombre maximal d'émissions LCP configure-request.
Fixe à n (10 par défaut) le nombre maximal de configure-NAKs retournés avant de commencer à envoyer des configure-Rejects à la place.
Fixe à n (10 par défaut) le nombre maximal d'émissions LCP terminate-request.
Fixe à n secondes (3 s par défaut) le délai LCP restart (dépassement de temps de retransmission).
Fixe à nom le nom logique du lien. Pppd créera un fichier nommé ppp-nom.pid dans /var/run (ou /etc/ppp sur certains systèmes), contenant son ID de processus. Ce peut être utile pour déterminer quelle instance de pppd est responsable du lien vers un correspondant donné. C'est une option privilégiée.
N'utilise pas les lignes de contrôle du modem. Avec cette option, pppd ignorera l'état du signal CD (Carrier Detect = détection de porteuse) en provenance du modem, et ne modifiera pas l'état du signal DTR (Data Terminal Ready = terminal prêt).
Envoie les messages de log au descripteur de fichier n. Pppd enverra les messages de log (outre leur envoi à syslog) à au plus un fichier OU descripteur de fichier, donc cette option et l'option logfile sont exclusives l'une de l'autre. Le comportement par défaut de pppd est d'envoyer les messages de log à stdout (fd=1), à moins que le port série ne soit déjà ouvert sur stdout.
Ajoute les messages de log (outre leur envoi à syslog) au fichier nomfichier. Le fichier est ouvert avec les droits de l'utilisateur qui a invoqué pppd, en mode append (ajout).
Utilise la base de mots de passe pour authentifier le correspondant, en utilisant le protocole PAP, et enregistre l'utilisateur dans le fichier système wtmp. Notez que le correspondant doit avoir une entrée dans le fichier /etc/ppp/pap-secrets et dans la base des mots de passe du système pour être autorisé à se connecter.
Termine la connexion après n secondes de disponibilité pour le trafic réseau (c.-à-d. n secondes après la première trame de NCP, protocole de contrôle réseau).
Arrête les tentatives de connexion après n (10 par défaut) échecs consécutifs. Une valeur de 0 signifie aucune limite.
Utilise les lignes de contrôle du modem. C'est le comportement par défaut. Avec cette option, pppd attendra de recevoir le signal CD (détection de porteuse) du modem pour ouvrir le périphérique série, à moins qu'un script de connexion ne soit spécifié, et il abaissera brièvement le signal DTR (terminal prêt) quand le connexion sera terminée, et avant d'exécuter le script de connexion. Sous Ultrix, cette option implique un contrôle de flux matériel, comme l'option crtscts.
Si pppd est utilisé comme serveur pour des clients Microsoft Windows, cette option permet de leur fournir une ou deux adresses de DNS. La première instance de cette option spécifie l'adresse du DNS primaire, et la deuxième (le cas échéant) celle du DNS secondaire. (Cette option était présente dans des versions précédentes de pppd sous le nom dns-addr.)
Si pppd est utilisé comme serveur pour des clients Microsoft Windows ou Samba, cette option permet de leur fournir une ou deux adresses de serveurs WINS (Windows Internet Name Service). La première instance de cette option spécifie l'adresse du WINS primaire, et la deuxième (le cas échéant) celle du WINS secondaire.
Fixe à nom le nom du système local, pour des usages d'authentification. C'est une option privilégiée. Avec cette option, pppd utilisera les lignes des fichiers secrets comportant nom comme deuxième champ, lors de la recherche d'un secret à utiliser pour authentifier le correspondant. De plus, à moins d'être écrasé par l'option user, nom sera utilisé comme nom à envoyer au correspondant lors de l'authentification du système local. (Notez que pppd n'ajoute pas le nom de domaine à name.)
Fixe à n le masque réseau de l'interface, un masque de 32 bits en "notation décimale pointée" (par ex. 255.255.255.0). Si cette option est passée, la valeur spécifiée est "ajoutée" (par un OR) avec le masque par défaut. Celui-ci est défini à partir de l'adresse IP distante négociée : c'est le masque approprié pour la classe de l'IP distante, composée (par un OR) avec les masques réseau de toutes les interfaces NON point à point du système qui sont sur le même réseau. (Note : sur certaines plates-formes, pppd utilisera toujours 255.255.255.255 comme masque réseau, si c'est la seule valeur appropriée pour une interface point-à-point).
Désactive la compression Adresse/Contrôle dans les deux directions.
Ne demande pas au correspondant de s'authentifier. Cette option est privilégiée.
Désactive la compression BSD-Compress ; pppd ne demandera, ni n'acceptera de compresser les paquets à l'aide du schéma BSD-Compress.
Désactive la négociation CCP (Compression Control Protocol). Cette option ne devrait être utilisée que si le correspondant est bogué et est perturbé par les requêtes de pppd concernant la négociation CCP.
Désactive le contrôle de flux matériel (RTS/CTS) sur le port série. Si aucune des options crtscts, nocrtscts, dtrcts, nodtrcts n'est passée, le contrôle de flux matériel sur le port série reste inchangé.
Cette option est synonyme de nocrtscts. Chacune de ces options désactive toute forme de contrôle de flux matériel.
Désactive l'option defaultroute. L'administrateur système désireux d'empêcher toute création de routes par défaut par un utilisateur avec pppd peut le faire en plaçant cette option dans le fichier /etc/ppp/options.
Désactive la compression Deflate ; pppd ne demandera ni n'acceptera de compresser les paquets à l'aide du schéma Deflate.
Ne se détache pas du terminal de contrôle. Sans cette option, si un périphérique série autre que le terminal sur l'entrée standard est spécifié, pppd se passera en tâche de fond (via un fork).
Désactive la négociation IPCP et la communication IP. Cette option ne devrait être utilisée que si le correspondant est bogué et est perturbé par les requêtes de pppd concernant la négociation IPCP.
Désactive la négociation IPv6CP et la communication IPv6. Cette option ne devrait être utilisée que si le correspondant est bogué et est perturbé par les requêtes de pppd concernant la négociation IPv6CP.
Désactive le comportement par défaut quand aucune adresse IP locale n'est spécifiée, qui est de déterminer (si possible) l'adresse IP locale à partir du nom d'hôte. Avec cette option, le correspondant devra fournir l'adresse IP locale durant la négociation IPCP (sauf spécification explicite en ligne de commande ou dans un fichier d'options).
Désactive les protocoles IPXCP et IPX. Cette option ne devrait être utilisée que si le correspondant est bogué et est perturbé par les requêtes de pppd concernant la négociation IPXCP.
L'opposé de l'option ktune ; empêche pppd de changer les paramètres noyau.
N'envoie les messages de log à aucun fichier, ni descripteur de fichier. Cette option annule les options logfd et logfile.
Désactive la négociation de "nombre magique". Avec cette option, pppd ne peut pas détecter une ligne en boucle (locale). Cette option ne devrait être utilisée que si le correspondant est bogué.
Désactive la négociation de compression du champ protocole, dans les deux directions.
S'arrête dès qu'une connexion a eu lieu et s'est terminée. C'est l'option par défaut, à moins que l'option persist ou demand n'ait été spécifiée.
Ne demande ni n'accepte la compression Predictor-1.
Désactive l'option proxyarp. L'administrateur système qui désire empêcher les utilisateurs de créer des entrées proxy ARP par pppd peut le faire en spécifiant cette option dans le fichier /etc/ppp/options.
Normalement, pppd exige un terminal en périphérique. Avec cette option, pppd s'alloue lui-même une paire maître/esclave pseudo-terminal et utilise l'esclave comme terminal périphérique. Pppd créera un processus fils pour servir de "relai caractère", transférant les caractères entre le pseudo-tty maître et ses entrée et sortie standard. Ainsi, pppd enverra des caractères sur sa sortie standard et les recevra sur son entrée standard, même si ce ne sont pas des terminaux. Cette option augmente évidemment le temps de latence, et la charge CPU du transfert de données par l'interface ppp. Aucun nom de périphérique explicite ne doit être passé si cette option est utilisée.
Désactive la compression d'en-tête TCP/IP de Van Jacobson dans les deux directions.
Désactive l'option de compression de l'ID-connexion dans la compression Van Jacobson de l'en-tête TCP/IP. Avec cette option, pppd n'omettra pas l'octet ID-connexion des en-têtes TCP/IP compressés Van Jacobson, ni ne demandera au correspondant de le faire.
Indique que tous les secrets du fichier /etc/ppp/pap-secrets qui sont utilisés pour authentifier le correspondant sont encryptés, et donc que pppd ne doit pas accepter de mot de passe qui, avant encryptage, est identique au secret trouvé dans le fichier /etc/ppp/pap-secrets.
Fixe à n (10 par défaut) le nombre maximal d'émissions de requêtes d'authentification PAP.
Fixe à n secondes (3s par défaut) le délai de relancement de PAP (expiration de réémission).
Fixe à n secondes (0 = aucune limite) le temps maximum que pppd attendra pour que le correspondant s'authentifie.
Spécifie un filtre à appliquer aux paquets de données envoyés et reçus, pour déterminer lesquels sont autorisés à passer. Les paquets rejetés par le filtre sont purement oubliés. Cette option peut être utilisée pour empêcher certains démons réseau (comme routed) d'activer le lien ppp pour rien, ou pour fournir des capacités pare-feu de base. La syntaxe d'expression-filtre est décrite dans tcpdump(1), sauf que les qualificateurs qui ne sont pas pertinents pour une liaison PPP, comme ether et arp, ne sont pas autorisés. Généralement, l'expression-filtre doit être entre guillemets pour éviter que les blancs ne soient interprétés par le shell. Notez qu'il est possible d'appliquer des contraintes différentes aux paquets entrants et sortants, en utilisant les qualificateurs inbound et outbound. Cette option n'est pour l'instant disponible que sous NetBSD, et seulement si le noyau et pppd ont tous deux été compilés avec PPP_FILTER défini.
Ne s'arrête pas à la fin d'une connexion ; essaie plutôt de la rouvrir.
Charge la bibliothèque partagée de nomfichier en module (plugin). C'est une option privilégiée.
Demande au correspondant de compresser les trames qu'il envoie avec le schéma Predictor-1, et accepte d'envoyer des trames ainsi compressées en cas de demande. Cette option n'a d'effet que si le pilote noyau gère la compression Predictor-1.
Permet aux membres du groupe nom-groupe d'utiliser les options privilégiées. C'est une option privilégiée ! Cette option est à manipuler avec précaution, car il n'y a pas de garantie que les membres de nom-groupe ne puissent utiliser pppd pour devenir root. Considérez que c'est équivalent à mettre les membres de nom-groupe dans le groupe kmem ou disk.
Ajoute une entrée à la table ARP [Address Resolution Protocol] de ce système, avec l'adresse IP du correspondant et l'adresse ethernet du système local. Cela aura pour effet de faire croire aux autres systèmes du réseau local ethernet que le correspondant est sur le même réseau physique.
Spécifie que le script de commandes doit être utilisé pour communiquer, au lieu d'un périphérique terminal spécifique. Pppd s'allouera une paire maître/esclave pseudo-tty et utilisera l'esclave comme terminal périphérique. Le script sera lancé comme processus fils, avec pour entrée/sortie standard le pseudo-tty maître. Aucun nom de périphérique explicite ne doit être donné si cette option est utilisée. (Note : si l'option record est utilisée en conjonction avec celle-ci, le processus fils aura des pipes sur ses entrée/sortie standard).
Avec cette option, pppd acceptera du correspondant tous les caractères de contrôle, y compris ceux marqués dans l'asyncmap de réception. Sans cette option, pppd rejettera ces caractères, comme il est spécifié dans le RFC1662. Cette option ne devrait être utilisée que si le correspondant est bogué.
Spécifie que pppd doit enregistrer tous les caractères envoyés et reçus dans le fichier nomfichier. Ce fichier est ouvert en mode append (ajout), avec l'UID et les permissions de l'utilisateur. Cette option est implémentée en utilisant un pseudo-tty et un processus pour transférer les caractères entre le pseudo-tty et le périphérique série réel, donc elle augmente la charge CPU et le temps de latence du transfert de données par l'interface ppp. Les caractères sont stockées dans un format balisé, avec horodatage, qui peut être consulté par la suite grâce au programme pppdump(8).
Fixe à nom le nom supposé du système distant, en vue de l'authentification.
Avec cette option, pppd refusera de s'authentifier auprès du correspondant via CHAP.
Avec cette option, pppd refusera de s'authentifier auprès du correspondant via PAP.
Demande à l'hôte de s'authentifier via CHAP (Challenge Handshake Authentication Protocol).
Demande à l'hôte de s'authentifier via PAP (Password Authentication Protocol).
Pendant l'enregistrement (log) des paquets PAP, cette option force pppd à montrer en clair le mot de passe dans le message de log.
Avec cette option, pppd n'enverra pas de paquets LCP pour démarrer une connexion jusqu'à ce qu'un paquet LCP valide soit reçu du correspondant (comme pour l'option 'passive' des anciennes versions de pppd).
Utilise l'encodage série HDLC synchrone au lieu d'asynchrone. Supporte actuellement les adaptateurs Microgate Synclink sous Linux et FreeBSD 2.2.8 et plus récents.
Avec cette option, pppd se détache de son terminal de contrôle dès que la connexion ppp est établie (au moment où le premier protocole réseau, en général IP, se met en place).
Force l'utilisation du nom d'hôte (avec ajout du nom de domaine s'il est donné) comme nom du système local, pour l'authentification (écrase l'option name). Cette option n'est normalement pas nécessaire, puisque l'option name est privilégiée.
Demande au correspondant une ou deux adresses de serveurs DNS. Les adresses fournies (le cas échéant) sont passées au script /etc/ppp/ip-up dans les variables d'environnement DNS1 et DNS2. En plus, pppd créera un fichier /etc/ppp/resolv.conf contenant une ou deux lignes de serveurs de nom, avec les adresses fournies.
Fixe à nom le nom utilisé pour authentifier le système local auprès du correspondant.
Fixe à n (entre 2 et 16, inclus) le nombre maximal de slots de connexion à utiliser par le code de (dé)compression des en-têtes TCP/IP de Van Jacobson.
Lance l'exécutable ou la commande shell spécifié par script avant de commencer la négociation PPP, et après le script de connexion (le cas échéant). Une valeur de cette option spécifiée par une source privilégiée ne peut pas être outrepassée par un utilisateur non privilégié.
Utilise le contrôle de flux logiciel (c.-à-d. XON/XOFF) sur le port série.

FICHIERS D'OPTIONS

Les options peuvent être spécifiées dans des fichiers ou sur la ligne de commande. Pppd lit les options dans les fichiers /etc/ppp/options, ~/.ppprc et /etc/ppp/options.nomtty (dans cet ordre) avant de traiter les options de la ligne de commande. (En réalité, les options de la ligne de commande sont d'abord parcourues une fois, pour trouver le nom du terminal, avant que options.nomtty ne soit lu). Pour former le nom du fichier options.ttyname, le "/dev/" initial est supprimé, et tout caractère / restant est remplacé par un point.

Un fichier d'option est analysé en une série de mots, délimités par des blancs. Un blanc peut être inclus dans un mot en plaçant le mot entre guillemets ("") Un backslash (\) protège le caractère suivant. Un dièse (#) signale un commentaire, qui continue jusqu'à la fin de la ligne. Il n'y a aucune restriction à utiliser les options file ou call à l'intérieur d'un fichier d'options.

SÉCURITÉ

pppd fournit à l'administration système un contrôle d'accès suffisant pour autoriser un accès PPP sur une machine serveur à des utilisateurs légitimes, sans compromettre la sécurité du serveur, ni celle du réseau local. Ce contrôle est fourni par les restrictions sur les adresses IP que peut utiliser le correspondant, fondées sur son identité authentifiée (le cas échéant) et sur les restrictions imposées aux options que peut employer un utilisateur non privilégié. Plusieurs options de pppd sont privilégiées, en particulier celles qui permettent d'établir des configurations potentiellement non sûres. Ces options ne sont acceptées que dans des fichiers qui sont sous le contrôle de l'administrateur système, ou si pppd est lancé par root.

Le comportement par défaut de pppd est de ne permettre à un correspondant non authentifié d'utiliser une adresse IP donnée que si le système n'a pas déjà de route vers cette adresse. Par exemple, un système avec une connexion permanente vers l'Internet a normalement une route par défaut, et donc tous les correspondants devront s'authentifier pour établir une connexion. Sur un tel système, l'option auth est activée par défaut. Réciproquement, un système où un lien PPP est la seule connexion à l'Internet n'a normalement pas de route par défaut, donc le correspondant aura le droit d'utiliser presque toute adresse IP sans s'authentifier.

Comme indiqué ci-dessus, certaines options sensibles du point de vue sécurité sont privilégiées, c'est-à-dire qu'elle ne peuvent pas être employées par un utilisateur ordinaire non privilégié, lançant un pppd setuid-root, soit sur la ligne de commande soit dans un fichier de configuration utilisateur comme ~/.ppprc ou lu par l'option file. Les options privilégiées peuvent être utilisées dans le fichier /etc/ppp/options ou dans tout fichier d'options lu par l'option call. Si pppd est lancé par root, les options privilégiées peuvent être utilisées sans restriction.

Quand il ouvre un périphérique, pppd utilise soit l'uid de l'utilisateur réel, soit l'uid root (0), selon que le nom de périphérique a été spécifié par l'utilisateur ou par l'administrateur. Si le nom de périphérique provient d'une source privilégiée (/etc/ppp/options ou un fichier lu par l'option call), pppd utilise les privilèges root pour ouvrir le périphérique. Ainsi, en créant un fichier approprié sous /etc/ppp/peers, l'administrateur système peut permettre à des utilisateurs d'établir une connexion ppp via un périphérique auquel ils n'ont normalement pas accès. Dans les autres cas, pppd utilise l'UID réel de l'utilisateur appelant pour ouvrir le périphérique.

AUTHENTIFICATION

L'authentification est le processus par lequel l'un des systèmes convainc l'autre de son identité. Cela implique que le premier système envoie au second son nom, accompagné d'une information secrète qui ne peut être connue que de l'utilisateur patenté de ce nom. Dans un tel échange, le premier système est appelé "client" et l'autre, "serveur". Le client a un nom grâce auquel il s'identifie auprès du serveur, et la réciproque est vraie. Généralement, le client patenté partage un secret (ou mot de passe) avec le serveur, et s'authentifie en prouvant qu'il le connaît. Très souvent, les noms utilisés pour l'authentification correspondent aux noms d'hôte internet des systèmes, mais ce n'est pas fondamental.

Actuellement, pppd supporte deux protocoles d'authentification : PAP (Password Authentication Protocol, ou authentification par mot de passe) et CHAP (Challenge Handshake Authentication Protocol, authentification par "défi à relever"). PAP implique que le client envoie son nom et un mot de passe en clair pour s'authentifier. Avec CHAP, c'est le serveur qui initie l'échange en envoyant au client un défi (et le nom du serveur). Le client doit répondre avec son nom, plus une valeur de hachage dérivée du secret partagé et du défi, afin de prouver qu'il connaît le secret.

Comme le protocole PPP est symétrique, il permet aux deux correspondants d'exiger chacun que l'autre s'authentifie. Dans ce cas, deux échanges séparés et indépendants auront lieu. Les deux peuvent utiliser des protocoles différents et, en principe, des noms différents peuvent être utilisés lors des deux échanges.

Le comportement par défaut de pppd est d'accepter de s'authentifier si on le lui demande, et de ne pas exiger d'authentification de son correspondant. Cependant, pppd n'acceptera pas de s'authentifier par un protocole particulier s'il ne connaît pas de secret qui le lui permette.

Pppd stocke les secrets à utiliser lors de l'authentification dans les fichiers secrets (/etc/ppp/pap-secrets pour PAP, /etc/ppp/chap-secrets pour CHAP). Les deux fichiers ont le même format. Les fichiers secrets peuvent aussi bien contenir les secrets à utiliser pour authentifier le système local auprès des correspondants que ceux utilisés pour authentifier les correspondants.

Chaque ligne d'un fichier de secrets contient un secret. Un secret donné est spécifique d'une paire client-serveur : il ne peut être utilisé que pour authentifier ce client auprès de ce serveur. Chaque ligne dans un fichier secrets a au moins 3 champs : le nom du client, le nom du serveur, et le secret. Ces champs peuvent être suivis par une liste d'adresses IP que le client spécifié peut utiliser pour se connecter au serveur spécifié.

Un fichier secrets est analysé en mots, comme un fichier d'options, donc le nom du client, le nom du serveur et le champ secret doivent être constitué d'un mot chacun, les blancs et autres caractères spéciaux devant être protégés par des guillemets ou un \. Notez que la casse est importante dans les noms de client et de serveur, et dans les secrets.

Si le secret commence par un `@', ce qui suit est pris comme le nom d'un fichier dans lequel lire le secret. Un "*" dans le nom du client ou du serveur correspond à n'importe quel nom. Quand il sélectionne un secret, pppd prend celui qui correspond le mieux, c'est-à-dire celui avec le moins de jokers.

Tous les mots suivants sur la même ligne sont pris comme liste d'adresses IP acceptables pour le client correspondant. S'il n'y a que trois mots sur une ligne, ou si le premier mot est "-", toutes les adresses IP sont interdites. Pour autoriser toutes les adresses, utilisez "*". Un mot commençant par "!" indique que l'adresse suivante n'est pas acceptable. Une adresse peut être suivie par un "/" et un nombre n, pour spécifier tout un sous-réseau, c'est-à-dire toutes les adresses qui ont les mêmes n bits de poids fort. Avec cette forme, l'adresse peut être suivie d'un signe "+" pour indiquer qu'une adresse du sous-réseau est autorisée, basée sur le numéro d'unité de l'interface ppp utilisée. Dans ce cas, la partie hôte de l'adresse sera fixée au numéro d'unité plus un. [NdT : en clair, avec une adresse de 172.16.0.0/16+, l'interface ppp0 utilisera l'adresse 172.16.0.1, ppp1 utilisera 172.16.0.2, etc.]

Ainsi un fichier de secrets contient à la fois les secrets à utiliser pour authentifier les autres hôtes et les secrets utilisés pour s'authentifier auprès des autres. Quand pppd authentifie son correspondant (c'est-à-dire vérifie son identité), il choisit un secret avec le nom du correspondant dans le premier champ et le nom du système local dans le deuxième champ. Le nom du système local est par défaut le nom d'hôte, flanqué du nom de domaine si l'option domain est passée. Ce comportement par défaut peut être outrepassé par l'option name, sauf si l'option usehostname est utilisée.

Quand pppd choisit un secret pour s'authentifier auprès du correspondant, il commence par déterminer le nom qu'il va utiliser pour s'identifier. Ce nom peut être spécifié par l'utilisateur grâce à l'option user. Sans cette option, le nom pris par défaut est celui du système local, déterminé comme indiqué au paragraphe précédent. Pppd cherche alors un secret comportant ce nom en premier champ et le nom du correspondant dans le deuxième champ. Pppd connaîtra le nom du correspondant si l'authentification CHAP est utilisée, car il est envoyé avec le "défi". Mais si PAP est utilisé, pppd devra déterminer le nom du correspondant à partir des options données par l'utilisateur. Celui-ci peut spécifier directement le nom du correspondant avec l'option remotename. Autrement, si l'adresse IP distante a été spécifiée par un nom (et pas sous forme numérique), ce nom sera utilisé comme nom du correspondant. Sans aucune indication, pppd utilisera la chaîne vide comme nom de correspondant.

Lors de l'authentification du correspondant avec PAP, le mot de passe fourni est d'abord comparé avec le secret contenu dans le fichier de secrets. Si le mot de passe ne correspond pas au secret, le mot de passe est encrypté par crypt(), et de nouveau comparé au secret. Ainsi, les secrets d'authentification peuvent être stockés sous forme encryptée si désiré. Si l'option papcrypt est passée, la première comparaison (en clair) est omise, pour plus de sécurité.

De plus, si l'option login a été spécifiée, le nom d'utilisateur et le mot de passe sont encore vérifiés par rapport à la base des mots de passe système. Ainsi, l'administrateur système peut configurer le fichier pap-secrets pour permettre l'accès PPP à certains utilisateurs seulement, et pour restreindre l'ensemble des adresses IP que chaque utilisateur peut utiliser. Typiquement, en utilisant l'option login, le secret dans /etc/ppp/pap-secrets serait "", qui correspondra à n'importe quel mot de passe fourni par le correspondant. Cela permet d'éviter de mettre le même secret en deux endroits différents.

L'authentification doit se terminer avec succès avant qu'IPCP (ou tout autre Protocole de Contrôle Réseau -NCP, Network Control Protocol-) ne démarre. Si le correspondant doit s'authentifier et n'en est pas capable, pppd coupera la connexion (en fermant LCP). Si IPCP négocie une adresse IP inacceptable pour l'hôte distant, IPCP sera fermé. Les paquets IP ne peuvent être transmis que si IPCP est ouvert.

Dans certains cas, il est nécessaire de permettre à certains hôtes qui ne peuvent pas s'authentifier de se connecter et d'utiliser une adresse IP d'une classe restreinte, même si l'hôte local exige en règle générale une authentification. Si le correspondant refuse de s'authentifier quand ça lui est demandé, pppd considère cela comme une authentification PAP avec un nom d'utilisateur et un mot de passe vides. Ainsi, en ajoutant au fichier pap-secrets une ligne avec des chaînes vides comme client et mot de passe, il est possible d'autoriser un accès restreint à des hôtes qui refusent de s'authentifier.

ROUTAGE

Quand la négociation IPCP se termine avec succès, pppd informe le noyau des adresses IP locale et distante pour l'interface PPP. C'est suffisant pour créer une route vers l'extrémité du lien, qui va permettre aux correspondants d'échanger des paquets IP. La communication avec d'autres machines requiert généralement des modifications supplémentaires dans les tables de routage ou dans les tables ARP (Address Resolution Protocol). Dans la plupart des cas, les options defaultroute ou proxyarp sont suffisantes, mais dans certains cas, d'autres interventions sont nécessaires. Elles peuvent être spécifiées dans le script /etc/ppp/ip-up.

Il est souvent nécessaire de rajouter une route par défaut via l'hôte distant, dans le cas d'une machine dont la seule connexion à l'Internet se fait par l'interface ppp. L'option defaultroute permet à pppd de créer cette route par défaut au démarrage d'IPCP, et de la détruire dès que le lien est coupé.

Dans certains cas, il est nécessaire d'utiliser un proxy ARP, par exemple sur une machine serveur connectée à un LAN, afin de permettre aux autres machines locales de communiquer avec l'hôte distant. L'option proxyarp permet à pppd de rechercher une interface réseau sur le même sous-réseau que l'hôte distant (une interface supportant le broadcast et ARP, ni loopback, ni interface point-à-point). S'il en trouve une, pppd crée une entrée ARP publique et permanente avec l'adresse IP de l'hôte distant et l'adresse MAC de l'interface réseau trouvée.

Quand l'option demand est utilisée, les adresses IP de l'interface ont déjà été fixées au moment où IPCP entre en action. Si pppd n'a pas pu négocier les mêmes adresses que celles utilisées pour configurer l'interface (par exemple si le correspondant est un FAI qui utilise l'attribution dynamique d'adresses IP), il est obligé de changer les adresses IP de l'interface. Cela peut couper les connexions IP existantes, de sorte que l'utilisation de la connexion à la demande avec des correspondants qui utilisent l'attribution dynamique n'est pas recommandée.

EXEMPLES

Les exemples suivants supposent que le fichier /etc/ppp/options contient l'option auth (comme dans le fichier /etc/ppp/options par défaut dans la distribution de ppp).

L'usage le plus commun de pppd est probablement la connexion à un FAI. Cela peut être fait avec une commande de type

pppd call fai

où le fichier /etc/ppp/peers/fai est configuré par l'administrateur système, pour contenir quelque chose comme :

ttyS0 19200 crtscts
connect '/usr/sbin/chat -v -f /etc/ppp/chat-fai'
noauth

Dans cet exemple, on utilise chat pour appeler le modem du FAI, et initier la séquence de login nécessaire. Le fichier /etc/ppp/chat-fai contient le script utilisé par chat ; il pourrait par exemple contenir quelque chose comme :

ABORT "NO CARRIER"
ABORT "NO DIALTONE"
ABORT "ERROR"
ABORT "NO ANSWER"
ABORT "BUSY"
ABORT "Username/Password Incorrect"
"" "at"
OK "at&d0&c1"
OK "atdt2468135"
"name:" "^Umyuserid"
"word:" "\qmypassword"
"ispts" "\q^Uppp"
"~-^Uppp-~"

Voir la page de man de chat(8) pour des détails sur les scripts chat.

Pppd peut aussi être utilisé pour fournir un service d'appel ppp entrant pour les utilisateurs. Si les utilisateurs ont déjà des comptes Unix, la manière la plus simple d'installer le service ppp est de laisser les utilisateurs se connecter à leurs comptes et lancer pppd (avec les droits setuid-root) avec une commande de type

pppd proxyarp

Pour permettre à un utilisateur d'utiliser les services PPP, vous devez attribuer une adresse IP à sa machine et créer une entrée dans /etc/ppp/pap-secrets ou /etc/ppp/chap-secrets (selon la méthode d'authentification), afin que la machine de l'utilisateur puisse s'authentifier. Par exemple, si Joe a une machine appelée "joespc" qui est autorisée à se connecter à la machine appelée "serveur" et utilise l'adresse IP joespc.my.net, vous devrez ajouter à /etc/ppp/pap-secrets ou /etc/ppp/chap-secrets une entrée :

joespc serveur "joe's secret" joespc.my.net

Sinon, vous pouvez créer un utilisateur fictif appelé (par exemple) "ppp", dont le shell de connexion est pppd et dont le répertoire est /etc/ppp. Les options à utiliser quand pppd est lancé de cette façon peuvent être spécifiées dans /etc/ppp/.ppprc.

Si votre connexion série est quelque chose de plus compliqué qu'un bout de fil de cuivre (comme un modem), vous pouvez avoir à protéger certains caractères de contrôle par une séquence d'échappement. En particulier, il est souvent utile de protéger XON (^Q) et XOFF (^S), en utilisant asyncmap a0000. Si le path inclut un telnet, vous devriez probablement protéger aussi ^] (asyncmap 200a0000). Si le path inclut un rlogin, vous devrez utiliser l'option escape ff sur l'hôte qui fait tourner le client rlogin, puisque de nombreuses implémentations de rlogin ne sont pas transparentes : elles suppriment la séquence [0xff, 0xff, 0x73, 0x73, suivie de 8 octets quelconques] du flux.

DIAGNOSTICS

Les messages sont envoyés au démon syslog, indiqué par LOG_DAEMON. (Ce comportement peut être outrepassé en recompilant pppd avec la macro LOG_PPP définie sur le service désiré.) Pour pouvoir consulter les messages d'erreur et de débogage, vous devrez éditer votre fichier /etc/syslog.conf pour diriger les messages vers le périphérique ou fichier de sortie voulu.

L'option debug permet d'enregistrer tous les paquets de contrôle transmis, c'est-à-dire les paquets LCP, PAP, CHAP et IPCP. Cela peut être utile si la négociation PPP ou l'authentification échoue. Si le débogage est activé à la compilation, l'option debug enregistre aussi les autres messages de débogage.

Le débogage peut également être activé ou désactivé en envoyant un signal SIGUSR1 au processus pppd. Ce signal agit comme un commutateur.

VALEUR DE RETOUR

La valeur de retour (exit status) de pppd est utilisée pour indiquer si une erreur a été détectée, ou préciser la raison de la déconnexion. Les valeurs utilisées sont :

0
Pppd s'est détaché du terminal, ou la connexion a été établie avec succès puis s'est terminée à la demande du correspondant.
1
Une erreur fatale de quelque sorte que ce soit a eu lieu, comme l'échec d'un appel système essentiel ou le dépassement de la mémoire virtuelle.
2
Une erreur a été détectée à l'analyse des options passées, comme l'emploi de deux options exclusives l'une de l'autre.
3
Pppd n'est pas setuid-root et l'utilisateur l'invoquant n'est pas root.
4
Le noyau ne supporte pas PPP ; par exemple, le pilote noyau PPP n'est pas inclus ou ne peut pas être chargé.
5
Pppd s'est terminé à la réception d'un signal SIGINT, SIGTERM ou SIGHUP.
6
Le port série n'a pas pu être verrouillé.
7
Le port série n'a pas pu être ouvert.
8
Le script de connexion a échoué (a retourné une valeur de sortie non nulle).
9
La commande spécifiée en argument à l'option pty n'a pas pu être lancée.
10
La négociation PPP a échoué, c'est-à-dire qu'elle n'a pas atteint le point où un protocole réseau (par ex. IP) est lancé.
11
Le système distant a refusé de (ou a échoué à) s'authentifier.
12
Le lien s'est établi avec succès, puis s'est terminé pour être resté trop longtemps au repos.
13
Le lien s'est établi avec succès, puis s'est terminé quand le temps limite de connexion a été atteint.
14
Le rappel (callback) a été négocié et un appel entrant devrait arriver incessamment.
15
Le lien a été coupé car le correspondant ne répond pas aux "echo requests".
16
Le lien a été coupé par le raccrochage du modem.
17
La négociation PPP a échoué car une boucle (loopback) série a été détectée.
18
Le script d'initialisation a échoué (a retourné une valeur de sortie non nulle).
19
On n'a pas réussi à s'authentifier auprès du correspondant (gasp !)

SCRIPTS

Pppd invoque des scripts à différents moments du processus de connexion, qui peuvent être utilisés pour des configurations secondaires spécifiques à l'hôte local. Ces scripts sont habituellement des scripts shell, mais peuvent aussi être des binaires exécutables. Pppd n'attend pas que ces scripts finissent. Les scripts sont exécutés en tant que root (avec les uid réel et effectif à 0), et peuvent donc faire des choses comme la mise à jour des tables de routage ou le lancement de démons privilégiés. Vérifiez que le contenu de ces scripts ne compromette pas la sécurité de votre système. Pppd lance ces scripts avec les entrée, sortie et erreur standard redirigées vers /dev/null, et avec un environnement vide, sauf pour les variables d'environnement qui donnent des informations sur le lien. Ces variables d'environnement sont :

Le nom du périphérique tty série utilisé.
Le nom de l'interface réseau utilisée.
L'adresse IP locale, pour l'hôte local. Fixée seulement après la mise en place d'IPCP.
L'adresse IP distante, pour l'hôte distant. Fixée seulement après la mise en place d'IPCP.
Le nom authentifié du correspondant. Fixé seulement si le correspondant s'authentifie.
Le débit (en bauds) du périphérique tty.
L'uid réel de l'utilisateur qui a invoqué pppd.
Le nom d'utilisateur de l'utilisateur réel qui a invoqué pppd. Toujours fixé.

Pour les scripts ip-down et auth-down, pppd fixe aussi les variables suivantes, qui donnent des statistiques sur la connexion :

Le nombre de secondes entre le début de la négociation PPP et la fin de la connexion.
Le nombre d'octets envoyés (au niveau du port série) pendant la connexion.
Le nombre d'octets reçus (au niveau du port série) pendant la connexion.
Le nom logique du lien, fixé avec l'option linkname.

Pppd invoque les scripts suivants s'ils existent. S'ils n'existent pas, cela ne constitue pas une erreur.

/etc/ppp/auth-up
Un programme ou script qui est exécuté après l'authentification du système distant. Il est exécuté avec les paramètres
interface-name peer-name user-name tty-device speed
Notez que ce script n'est pas exécuté si le correspondant ne s'authentifie pas, par exemple quand l'option noauth est utilisée.
/etc/ppp/auth-down
Un programme ou script qui est exécuté quand le lien est coupé, si /etc/ppp/auth-up a précédemment été exécuté. Il est exécuté de la même manière et avec les mêmes paramètres que /etc/ppp/auth-up.
/etc/ppp/ip-up
Un programme ou script qui est exécuté dès que le lien est disponible pour envoyer et recevoir des paquets IP (c'est-à-dire dès que IPCP est activé). Il est exécuté avec les paramètres
interface-name tty-device speed local-IP-address remote-IP-address ipparam
/etc/ppp/ip-down
Un programme ou script qui est exécuté dès que le lien n'est plus disponible pour la transmission de paquets IP. Il peut être utilisé pour annuler les effets du script /etc/ppp/ip-up. Il est exécuté de la même manière et avec les mêmes paramètres que /etc/ppp/ip-up.
/etc/ppp/ipv6-up
Comme /etc/ppp/ip-up, sauf qu'il est exécuté dès que le lien est disponible pour envoyer et recevoir des paquets IPv6. Il est exécuté avec les paramètres
interface-name tty-device speed local-link-local-address remote-link-local-address ipparam
/etc/ppp/ipv6-down
Comme /etc/ppp/ip-down, sauf qu'il est exécuté dès que le lien est fermé à la transmission de paquets IPv6. Il est exécuté avec les mêmes paramètres que le script ipv6-up.
/etc/ppp/ipx-up
Un programme ou script qui est exécuté dès que le lien est disponible pour envoyer et recevoir des paquets IPX (c.-à-d. dès que IPXCP est activé). Il est exécuté avec les paramètres
interface-name tty-device speed network-number local-IPX-node-address remote-IPX-node-address local-IPX-routing-protocol remote-IPX-routing-protocol local-IPX-router-name remote-IPX-router-name ipparam pppd-pid
Les champs local-IPX-routing-protocol et remote-IPX-routing-protocol sont l'un des suivants :
NONE pour indiquer l'absence de protocole de routage
RIP pour indiquer que RIP/SAP devrait être utilisé
NLSP pour indiquer que Novell NLSP devrait être utilisé
RIP NLSP pour indiquer que RIP/SAP et NLSP devraient être utilisés ensemble
/etc/ppp/ipx-down
Un programme ou script qui est exécuté dès que le lien n'est plus disponible pour envoyer et recevoir des paquets IPX. Il peut être utilisé pour annuler les effets du script /etc/ppp/ipx-up. Il est invoqué de la même manière et avec les mêmes arguments que le script ipx-up.

FICHIERS

/var/run/pppn.pid (BSD et Linux), /etc/ppp/pppn.pid
(autres systèmes) ID-Processus (PID) du processus pppd sur l'unité d'interface ppp numéro n.
/var/run/ppp-nom.pid (BSD et Linux), /etc/ppp/ppp-nom.pid (autres systèmes)
ID-Processus (PID) du processus pppd du lien logique nom (voir l'option linkname).
/etc/ppp/pap-secrets
Noms d'utilisateur, mots de passe et adresses IP pour l'authentification PAP. Ce fichier doit appartenir à root et n'être ni lisible ni inscriptible par aucun autre utilisateur. Pppd enverra un avertissement (warning) si ce n'est pas le cas.
/etc/ppp/chap-secrets
Noms d'utilisateur, mots de passe et adresses IP pour l'authentification CHAP. Ce fichier doit appartenir à root et n'être ni lisible ni inscriptible par aucun autre utilisateur. Pppd enverra un avertissement (warning) si ce n'est pas le cas.
/etc/ppp/options
Les options système par défaut pour pppd, lues avant les options utilisateur par défaut et les options en ligne de commande.
~/.ppprc
Les options utilisateur par défaut, lues avant /etc/ppp/options.ttyname.
/etc/ppp/options.nom-tty
Les options système par défaut pour le port série spécifié, lues après ~/.ppprc. Pour former le nom-tty de ce nom de fichier, tout /dev/ initial est supprimé du nom de port (si nécessaire), et tout slash (/) de la partie restante est converti en point.
/etc/ppp/peers
Un répertoire contenant les fichiers d'options qui peuvent contenir des options privilégiées, même si pppd est invoqué par un utilisateur autre que root. L'administrateur système peut créer des fichiers d'options dans ce répertoire pour permettre à des utilisateurs non privilégiés d'appeler sans demander au correspondant de s'authentifier, mais seulement vers certains correspondants de confiance.

VOIR AUSSI

Jacobson, V. Compressing TCP/IP headers for low-speed serial links. Février 1990.
Rivest, R. The MD5 Message-Digest Algorithm. Avril 1992.
McGregor, G. PPP Internet Protocol Control Protocol (IPCP). Mai 1992.
Lloyd, B.; Simpson, W.A. PPP authentication protocols. Octobre 1992.
Simpson, W.A. The Point-to-Point Protocol (PPP). Juillet 1994.
Simpson, W.A. PPP in HDLC-like Framing. Juillet 1994.
Haskin, D. IP Version 6 over PPP Décembre 1998.

NOTES

Les signaux suivants ont l'effet spécifié s'ils sont envoyés à pppd.

Ces signaux intiment à pppd l'ordre de couper le lien (en fermant LCP), de restaurer les paramètres du périphérique série et de se terminer.
Ce signal intime à pppd l'ordre de couper le lien, de restaurer les paramètres du périphérique série et de fermer le périphérique série. Si l'une des options persist ou demand a été spécifiée, pppd essaiera de rouvrir le périphérique série et de démarrer une autre connexion (après le délai holdoff). Sinon, pppd se terminera. Si ce signal est reçu pendant le délai holdoff, il dit à pppd de mettre fin immédiatement à ce délai.
Ce signal bascule l'état de l'option debug.
Ce signal dit à pppd de renégocier la compression. Cela peut être utile pour réactiver la compression après son abandon pour cause d'erreur fatale de décompression. (Ces erreurs sont généralement le signe d'un bogue dans l'une ou l'autre implémentation).

AUTEURS

Paul Mackerras (Paul.Mackerras@cs.anu.edu.au), basé sur le travail précédent de Drew Perkins, Brad Clements, Karl Fox, Greg Christy, et Brad Parker.

TRADUCTION FRANCAISE

Guillaume Allègre, LDP-fr <Guillaume.Allegre@imag.fr>, août 2000

AVERTISSEMENT SUR LA TRADUCTION

Il est possible que cette traduction soit imparfaite ou périmée. En cas de doute, veuillez vous reporter au document original en langue anglaise fourni avec le programme.